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Abstract 
This memo specifies procedures for modifying the Resource reSerVation 
Protocol (RSVP). This memo also lays out new assignment guidelines 


for number spaces for RSVP messages, object classes, class-types, and 
sub-objects. 


1. Introduction 


This memo specifies procedures for modifying the Resource reSerVation 
Protocol (RSVP) [RSVP], including (but not limited to) adding, 
updating, extending or obsoleting: messages, message formats and 
procedures, object classes and class types, object formats and 
procedures; header formats, error codes and subcodes and semantics, 
and procedures for sending, receiving, and addressing RSVP messages. 


IANA recognizes the following RSVP name spaces: Message Types, Class 
Names, Class Numbers, Class Types and Sub-objects, Virtual 
Destination Ports, and Error Codes and (Subcode) Values (all of these 
will collectively be referred to as RSVP entities in this document). 
This memo specifies ranges for each name space and assignment 
policies for each range. New RSVP name spaces must be defined in a 
Standards Track RFC which include guidelines for IANA assignments 
within the new name spaces. 


The assignment policies used in this document are: Standards Action 
(as defined in [IANA]), Expert Review, and Organization/Vendor 

Private (more simply, "Vendor Private"); the last two are defined in 
this document. The intent of these assignment policies is to ensure 
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that extensions to RSVP receive adequate review before code-points 
are assigned, without being overly rigid. Thus, if an extension is 
widely accepted and its ramifications are well understood, it may 
receive an assignment from the Standards Action space; however, if an 
extension is experimental in nature, it receives an assignment from 
the Expert Review space, and may, with maturity, move to Standards 
Track. Assignments from the Vendor Private space are not reviewed, 
but there are mechanisms in place to ensure that these codepoints can 
co-exist in a network without harm. 


A standards body other than the IETF that wishes to obtain an 
assignment for an RSVP entity must decide from which type of 
name/number space they desire their assignment be made from, and then 
submit the appropriate documentation. For example, if the assignment 
is to be made from a number space designated as Standards Action, a 
Standards Track RFC MUST be submitted in support of the request for 
assignment. 


This memo updates the IANA Considerations section (section 7) of 
[RSVP-TE], replacing the assignment policies stated there. 


Conventions used in this document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[KEYWORDS]. 


2. Assignment Policies for RSVP Entities 


For each of the RSVP name spaces identified by IANA, the space is 
divided into assignment ranges; the following terms are used in 
describing the procedures by which IANA assigns values: "Standards 
Action" (as defined in [IANA]), "Expert Review", and 
"Organization/Vendor Private", defined below. 


"Expert Review" ranges refer to values that are to be reviewed by an 
Expert designated by the IESG. The code points from these ranges are 
typically used for experimental extensions; such assignments MUST be 
requested by Experimental RFCs that document their use and 
processing, and the actual assignments made during the IANA actions 
for the document. Values from "Expert Review" ranges MUST be 
registered with IANA. 


"Organization/Vendor Private" ranges refer to values that are 
enterprise-specific; these MUST NOT be registered with IANA. For 
Vendor Private values, the first 4-octet word of the data field MUST 
be an enterprise code [ENT] as registered with the IANA SMI Network 
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Management Private Enterprise Codes, and the rest of the data 
thereafter is for the private use of the registered enterprise. (For 
each RSVP entity that has a Vendor Private range, it must be 
specified where exactly the data field starts; see below for 
examples.) In this way, different enterprises, vendors, or Standards 
Development Organizations (SDOs) can use the same code point without 
fear of collision. 


2.1. Message Types 


A Message Type is an 8-bit number that identifies the function of the 
RSVP message. Values from 0 through 239 are to be assigned by 
Standards Action. Values from 240 through 255 are to be assigned by 
Expert Review. 


2.2. Class Names and Numbers 


Each class of data objects in an RSVP message is identified by an all 
upper-case Class Name and an 8-bit Class Number (also known as 
Class-Num or C-Num). Class Numbers are divided broadly into three 
ranges (0-127, 128-191, and 192-255) determined by the two high-order 
bits of the Class-Num object (the ’b’ below represents a bit). 


Note: the first 32-bit word of an Object whose Class-—Num or Class- 
Type is from the Vendor Private range MUST be that vendor’s SMI 
enterprise code in network octet order (these enterprise codes can be 
obtained from, and registered with, IANA). An implementation 
encountering a Vendor Private object with an SMI enterprise code that 
it does not recognize MUST treat that object (and enclosing message) 
based on the Class-Num, as specified in [RSVP], section 3.10. 


o Class-Num = Obbbbbbb 


Class Numbers from 0 through 119 are to be assigned by 
Standards Action. Class Numbers from 120 through 123 are to be 
assigned by Expert Review. Class Numbers from 124 through 127 
are reserved for Vendor Private Use. 


o Class-Num = 10bbbbbb 
Class Numbers from 128 through 183 are to be assigned by 
Standards Action. Class Numbers from 184 through 187 are to be 


assigned by Expert Review. Class Numbers from 188 through 191 
are reserved for Vendor Private Use. 
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o Class-Num = 11bbbbbb 


Class Numbers from 192 through 247 are to be assigned by 
Standards Action. Class Numbers from 248 through 251 are to be 
assigned by Expert Review. Class Numbers from 252 through 255 
are reserved for Vendor Private Use. 


2.3. Class Types 


Within each object class there is an 8-bit Class Type (also known as 
a C-Type). Class Types are scoped to a Class Number. In general, 
the appropriateness of allowing assignments of Class Types through 
Expert Review or Vendor Private depends on the semantics of the Class 
Number itself. Thus, any new Class Number definition must specify an 
appropriate IANA Considerations policy for assigning additional Class 
Type values. 


For Class Numbers that pre-date this document (specifically, 0, 1, 
3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the 
default assignment policy for new Class Types is Standards Action, 
unless a Standards Track or Best Current Practice RFC supercedes 
this. 


2.3.1. Sub-objects 


Within an object, sub-objects may be defined, generally as a Type- 
Length-Value triple. This memo defines the assignment policies for 
sub-objects of EXPLICIT_ROUTE and RECORD_ROUTE. An RFC defining new 
sub-objects MUST state how IANA is to assign the sub-object Types. 


The EXPLICIT_ROUTE object [RSVP-TE] carries a variable length sub- 
object that is identified by a 7-bit Type field. Types 0 through 119 
are to be assigned by Standards Action. Types 120 through 123 are to 
be assigned by Expert Review. Types 124 through 127 are to be 
reserved for Vendor Private Use. 


The RECORD_ROUTE object [RSVP-TE] carries a variable length sub- 
object that is identified by an 8-bit Type field. Types 0 through 
191 are to be assigned by Standards Action. Types 192 through 251 
are to be assigned by Expert Review. Types 252 through 255 are to be 
reserved for Vendor Private Use. 


The first four octets of the sub-object contents of a Vendor Private 


sub-object of an EXPLICIT_ROUTE or RECORD_ROUTE object MUST be that 
vendor’s SMI enterprise code in network octet order. 
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2.4. Virtual Destination Ports 


Virtual destination ports are described in [RSVP-IPSEC], which also 
specifies how IANA assignments are to be made. 


2.5. Error Codes and Values 


An Error Code is an 8-bit quantity that appears in an ERROR_SPEC 
object to broadly define an error condition. With each Error Code 
there may be a 16-bit Error Value that further specifies the cause of 
the error. Error Value may be globally defined, in which case the 
sub-code component is assigned by IANA. 


Error Code values from 0 through 239 are to be assigned by Standards 
Action. Values from 240 through 251 are to be assigned by Expert 
Review. Values from 252 through 255 are reserved for Vendor Private 
Use. If the Error Code is for Vendor Private Use, the first four 
octets following the Error Value MUST be the vendor’s SMI enterprise 
code in network octet order. 


Globally defined Error Values are assigned by Standards Action. 
3. Modifying RSVP Procedures 


RSVP entities have associated procedures describing when and how they 
are to be sent, received, processed, and responded to. A change to a 
procedure that affects the processing of an RSVP entity that belongs 
to a range designated "Standards Action" MUST be documented in a 
Standards Track RFC. A change to a procedure that affects the 
processing of an RSVP entity that belongs to a range designated 
"Expert Review" MUST be documented in an Experimental RFC. 
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5. Security Considerations 
It is hoped that the procedures outlined in this memo will ensure 
that changes made to RSVP will be better reviewed and thus more 
architecturally sound, thereby enhancing the security both of the 
protocol and of networks deploying it. 


6. IANA Considerations 


See section 2. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
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Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the IETF’s procedures with respect to rights in IETF Documents can 
be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
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